This is a preview of the changelog of the next release. If this branch is not up-to-date with the current main branch, the changelog may not be accurate. Rebase your branch on the main branch to get the most accurate changelog.

Note that this might contain changes that are on main, but not yet released.

Changelog:

0.9.0 (2025-10-02)

⚠ BREAKING CHANGES

• silo: Multiple breaking changes to lineage configuration:
  • PreprocessingConfig: lineageDefinitionsFilename renamed to
    lineageDefinitionFilenames and changed from string to list
  • DatabaseConfig: generateLineageIndex changed from boolean to string
    (expects lineage definition filename)

Features

• silo: add a health endpoint that checks whether the api is able to answer requests (5422ff1)
• silo: remove TBB dependency (#985) (91ec897), closes #873
• silo: support multiple lineage systems (3908395)
• update arrow to version 21.0.0 (478366e)

Bug Fixes

• test: properly free request handlers in tests (0f9e0d9)

Multiple breaking changes to lineage configuration:

* PreprocessingConfig: `lineageDefinitionsFilename` renamed to `lineageDefinitionFilenames` and changed from string to array

* DatabaseConfig: `generateLineageIndex` changed from boolean to string (expects lineage filename with automatic prefix/suffix detection)

Would it make sense to change lineageDefinitionFilenames to an object? The values would be the lineage file and generateLineageIndex could then reference the keys there (instead of the filename with a autocomplete attempt that may be confusing and error prone).

# preprocessing config
lineageDefinitionFilenames:
  pangoLineage: 'my-pango-lineages.yaml'
  nextstrainClade: 'my-nextstrain-clades.yaml'
---
# db config
  metadata:
    - name: myPangoLineageField
      generateLineageInedx: pangoLineage

Edit: if I call my lineage file e.g. "lineage.yaml", would generateLineageInedx: '' be valid in the config (with the current implementation)?

Would it make sense to change lineageDefinitionFilenames to an object? The values would be the lineage file and generateLineageIndex could then reference the keys there (instead of the filename with a autocomplete attempt that may be confusing and error prone).

Unfortunately, this is not possible, as the preprocessing-config can also be supplied by CLI arguments / env vars, hence, it can only be a string. -> only partially true, we introduced a list type parameter instead, see later discussion

Mid-term I do not think this matters too much, as the current preprocessing should be replaced by a more idiomatic and dynamic API for schema management

Would it make sense to change lineageDefinitionFilenames to an object? The values would be the lineage file and generateLineageIndex could then reference the keys there (instead of the filename with a autocomplete attempt that may be confusing and error prone).

Unfortunately, this is not possible, as the preprocessing-config can also be supplied by CLI arguments / env vars, hence, it can only be a string.

Mid-term I do not think this matters too much, as the current preprocessing should be replaced by a more idiomatic and dynamic API for schema management

Ok that is unfortunate. I could imagine that we could still get keys from CLI arguments by implementing a syntax like --option 'key:value' but I'm not sure whether that's worth the trouble.

But I'd still like to get rid of the heuristics that try to autocomplete the filename. Do we need that at all? The DB config is written once and it doesn't really matter how long the config values are. We could simply require maintainers to put the whole filename there (maybe without the .yaml ending). That would be a lot more transparent, easier to explain and less error prone. IMO wouldn't lose anything.

Ok that is unfortunate. I could imagine that we could still get keys from CLI arguments by implementing a syntax like --option 'key:value' but I'm not sure whether that's worth the trouble.

We decided to change the code to store the parameter as a list directly, but CLI arguments and env vars will currently throw errors, when trying to define a list-type parameter (e.g. lineageDefinitionFilenames).

The follow-up issue #1010 has been added

We might wait with merging this (and thus needing to bump SILO to 0.9), until #1007 is fixed